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Tunneling IPX Traffic through IP Networks 


Status of this Memo 


This memo describes a method of encapsulating IPX datagrams within 
UDP packets so that IPX traffic can travel across an IP internet. 
This RFC specifies an IAB standards track protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 
Distribution of this memo is unlimited. 


Introduction 


Internet Packet eXchange protocol (IPX) is the internetwork protocol 
used by Novell’s NetWare protocol suite. For the purposes of this 
paper, IPX is functionally equivalent to the Internet Datagram 
Protocol (IDP) from the Xerox Network Systems (XNS) protocol suite 
[1]. This memo describes a method of encapsulating IPX datagrams 
within UDP packets [2] so that IPX traffic can travel across an IP 
internet [3]. 


This RFC allows an IPX implementation to view an IP internet as a 
single IPX network. An implementation of this memo will encapsulate 
IPX datagrams in UDP packets in the same way any hardware 
implementation might encapsulate IPX datagrams in that hardware’s 
frames. IPX networks can be connected thusly across internets that 
carry only IP traffic. 


Packet Format 


Each IPX datagram is carried in the data portion of a UDP packet. 
All IP and UDP fields are set normally. Both the source and the 
destination ports in the UDP packet should be set to the UDP port 
value allocated by the Internet Assigned Numbers Authority for the 
implementation of this encapsulation method. 


As with any UDP application, the transmitting party has the option of 
avoiding the overhead of the checksum by setting the UDP checksum to 
zero. Since IPX implementations never use the IPX checksum to guard 
IPX packets from damage, UDP checksumming is highly recommended for 
IPX encapsulation. 
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IP Header UDP Header IPX Header IPX packet data 
(20 or more octets) (8 octets) (30 octets) 


Figure 1: An IPX packet carried as data in a UDP packet. 
Reserved Packets 


The first two octets of the IPX header contain the IPX checksum. IPX 
packets are never sent with a checksum, so every IPX header begins 
with two octets of FF hex. Implementations of this encapsulation 
scheme should ignore packets with any other value in the first two 
octets immediately following the UDP header. Other values are 
reserved for possible future enhancements to this encapsulation 
protocol. 


Unicast Address Mappings 


IPX addresses consist of a four octet network number and a six octet 
host number. IPX uses the network number to route each packet 
through the IPX internet to the destination network. Once the packet 
arrives at the destination network, IPX uses the six octet host 
number as the hardware address on that network. 


Host numbers are also exchanged in the IPX headers of packets of 
IPX’s Routing Information Protocol (RIP). This supplies end nodes 
and routers alike with the hardware address information required for 
forwarding packets across intermediate networks on the way towards 
the destination networks. 


For implementations of this memo, the first two octets of the host 
number will always be zero and the last four octets will be the 
node’s four octet IP address. This makes address mapping trivial for 
unicast transmissions: the first two octets of the host number are 
discarded, leaving the normal four octet IP address. The 
encapsulation code should use this IP address as the destination 
address of the UDP/IP tunnel packet. 


Broadcasts between Peer Servers 


IPX requires broadcast facilities so that NetWare servers and IPX 
routers sharing a network can find one another. Since internet-—wide 
IP broadcast is neither appropriate nor available, some other 
mechanism is required. For this memo, each server and router should 
maintain a list of the IP addresses of the other IPX servers and 
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routers on the IP internet. I will refer to this list as the "peer 
list", to individual members as "peers", and to all the peers taken 
together, including the local node, as the "peer group". When IPX 


requests a broadcast, the encapsulation implementation simulates the 
broadcast by transmitting a separate unicast packet to each peer in 
the peer list. 


Because each peer list is constructed by hand, several groups of 
peers can share the same IP internet without knowing about one 
another. This differs from a normal IPX network in which all peers 
would find each other automatically by using the hardware’s broadcast 
facility. 


The list of peers at each node should contain all other peers in the 
peer group. In most cases, connectivity will suffer if broadcasts 
from one peer consistently fail to reach some other peer in the 
group. 


The peer list could be implemented using IP multicast [4], but since 
multicast facilities are not widely available at this time, no well- 
known multicast address has been assigned and no implementations 
using multicast exist. As IP multicast is deployed in IP 
implementations, it can be used by simply including in the peer list 
an IP multicast address for IPX servers and routers. The IP 
multicast address would replace the IP addresses of all peers which 
will receive IP multicast packets sent from this peer. 


Broadcasts by Clients 


Typically, NetWare client nodes do not need to receive broadcasts, so 
normally NetWare client nodes on the IP internet would not need to be 
included in the peer lists at the servers. 


On the other hand, clients on an IPX network need to send broadcasts 
in order to locate servers and to discover routes. A client 
implementation of UDP encapsulation can handle this by having a 
configured list of the IP addresses of all servers and routers in the 
peer group running on the IP internetwork. As with the peer list on 
a server, the client implementation would simulate the broadcast by 
sending a copy of the packet to each IP address in its list of IPX 
servers and routers. One of the IP addresses in the list, perhaps 
the only one, could be a broadcast address or, when available, a 
multicast address. This allows the client to communicate with 
members of the peer group without knowing their specific IP 
addresses. 


It’s important to realize that broadcast packets sent from an IPX 
client must be able to reach all servers and routers in the server 
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peer group. Unlike IP, which has a unicast redirect mechanism, IPX 
end systems are responsible for discovering routing information by 
broadcasting a packet requesting a router that can forward packets to 
the desired destination. If such packets do not tend to reach the 
entire server peer group, resources in the IPX internet may be 
visible to an end system, yet unreachable by it. 


Maximum Transmission Unit 


Although larger IPX packets are possible, the standard maximum 
transmission unit for IPX is 576 octets. Consequently, 576 octets is 
the recommended default maximum transmission unit for IPX packets 
being sent with this encapsulation technique. With the eight octet 
UDP header and the 20 octet IP header, the resulting IP packets will 
be 604 octets long. Note that this is larger than the 576 octet 
maximum size IP implementations are required to accept [3]. Any IP 
implementation supporting this encapsulation technique must be 
capable of receiving 604 octet IP packets. 


As improvements in protocols and hardware allow for larger, 
unfragmented IP transmission units, the 576 octet maximum IPX packet 
size may become a liability. For this reason, it is recommended that 
the IPX maximum transmission unit size be configurable in 
implementations of this memo. 


Security Issues 


Using a wide-area, general purpose network such as an IP internet in 
a position normally occupied by physical cabling introduces some 
security problems not normally encountered in IPX internetworks. 
Normal media are typically protected physically from outside access; 
IP internets typically invite outside access. 


The general effect is that the security of the entire IPX 
internetwork is only as good as the security of the entire IP 
internet through which it tunnels. The following broad classes of 
attacks are possible: 


1) Unauthorized IPX clients can gain access to resources through 
normal access control attacks such as password cracking. 


2) Unauthorized IPX gateways can divert IPX traffic to unintended 
routes. 
3) Unauthorized agents can monitor and manipulate IPX traffic 


flowing over physical media used by the IP internet and under 
control of the agent. 
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To a large extent, these security risks are typical of the risks 
facing any other application using an IP internet. They are 
mentioned here only because IPX is not normally suspicious of its 
media. IPX network administrators will need to be aware of these 
additional security risks. 


Assigned Numbers 
The Internet Assigned Numbers Authority assigns well-known UDP port 
numbers. It has assigned port number 213 decimal to the IPX 
encapsulation technique described in this memo [5]. 
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Security Considerations 


See the "Security Issues" section above. 
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